Cut 1.0-alpha - #379
Conversation
VERSION goes to 1.0-alpha and CHANGELOG's [Unreleased] becomes [1.0-alpha] dated 2026-08-04. Every item on the #367 checklist is closed: the open bugs (#358, #362, #363, #364, #376), the docs accuracy pass, the changelog, the single-engine and cross-engine benchmark re-measures, and a full five-major matrix green at 112 suites on each of PG15 through PG19. The extension's own default_version stays at 1.0-dev, and the changelog now says so rather than leaving it to be discovered. That field governs ALTER EXTENSION UPDATE; moving it needs an upgrade script that does not exist, and breaking installs to make a version string tidy is the wrong trade. SELECT extversion therefore reports 1.0-dev on a 1.0-alpha build. Adds a known-limitations section, because an alpha that ships its sharp edges in the tracker only is an alpha that hides them: the grouped parallel arm declined on expression grouping keys (#369), the fetch cache's real memory bound (#364), the index-fetch penalty being bounded rather than modelled (#376), and point-lookup cost growing with table width. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
ChronicallyJD
left a comment
ChronicallyJD
left a comment
There was a problem hiding this comment.
Reviewed. The cut is right and the two decisions you flagged are both the right call —
especially keeping default_version at 1.0-dev and saying so rather than renaming
the SQL file and inventing an upgrade script to make a string tidy. I verified the
known-limitations entries against my own measurements: 62 MB against a 32 MB cap is
what I measured on #364, and the 47% is 127,699 ms against 187,521. Both correct.
Putting the sharp edges in the changelog rather than only the tracker is the right
instinct, and I would have argued for it if you had not done it.
One blocker: README contradicts the file it cites
README.md:27:
It is pre-release; the version marker is
1.0-dev, recorded inVERSION.
This PR makes VERSION say 1.0-alpha. So the README asserts the contents of a file
that is in the same commit and disagrees with it. That is the first thing a reader
sees, and it points straight at VERSION to check.
README.md:12 has the same problem in the badge:
<a href="VERSION"><img src="badges/version.svg" alt="Version 1.0-dev"></a>and badges/version.svg itself renders version: 1.0-dev, so the badge needs
regenerating along with the alt text.
Suggested wording for line 27, which also carries your default_version point to
where people will actually hit it:
It is pre-release; the version marker is
1.0-alpha, recorded inVERSION. The extension's owndefault_versionis still
1.0-dev, soSELECT extversion FROM pg_extensionreports that.
Not blocking
The 1.0-dev references in PROVENANCE.md are all about the v1.0-dev tag and
the practice line it preserves. Those are historical fact and should stay exactly as
they are — I checked each one rather than pattern-matching the string.
pgcolumnar.control and pgcolumnar--1.0-dev.sql are the deliberate pair you
described, and they agree with each other.
Everything else checks out: VERSION, the [1.0-alpha] - 2026-08-04 heading, and the
checklist table all match what actually landed. Happy to see this merge once the README
matches VERSION; I can push that commit if you would rather not do another round.
1.0-alpha shipped with the front page contradicting the file it links to. VERSION reads 1.0-alpha; README said "the version marker is 1.0-dev, recorded in VERSION", one click from the file that disagrees. The badge said the same, in its alt text and in badges/version.svg. Raised on #379 before the merge and missed in the cut, so this is the follow-up rather than a new finding. The README now also carries the default_version note that was only in the changelog. That field stays 1.0-dev deliberately, because moving it needs an upgrade script that does not exist, so a user who checks SELECT extversion FROM pg_extension sees 1.0-dev on a 1.0-alpha build. The front page is where someone hits that surprise, so the explanation belongs there too. The badge SVG is widened from 104 to 118 pixels, because 1.0-alpha is two characters longer than 1.0-dev and the label would otherwise clip. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Point the README at 1.0-alpha (#379 follow-up)
2 participants
What
Closes #367.
VERSIONgoes to1.0-alpha,[Unreleased]becomes[1.0-alpha]dated 2026-08-04.
Every item on the checklist is closed:
Two decisions worth a reviewer's eye
The extension's
default_versionstays1.0-dev, and the changelog now says so.That field governs
ALTER EXTENSION UPDATE. Moving it means renamingpgcolumnar--1.0-dev.sqland adding an upgrade script that does not exist, andbreaking installs to make a version string tidy is the wrong trade for a pre-release.
SELECT extversion FROM pg_extensiontherefore reports1.0-devon a 1.0-alphabuild. Stated in the changelog preamble rather than left to be discovered.
A known-limitations section, in the changelog rather than only the tracker. An
alpha that ships its sharp edges in issues alone is an alpha that hides them:
settings off by default;
4 x (cap + retained indexes + groupBuffer), andthe measured 62 MB entry (#361's fetch cache is not bounded by 4x the cap: one entry measures 62 MB against 32 MB on a wide varlena table, and gets 1.14x #364), including why holding the bound costs 47% in
time;
prefix.
Verification
docs_style,smokeandharness_selftestpass on the cut tree. No source change,so the five-major matrix result for
a2027eastands.🤖 Generated with Claude Code